Internet third-party authentication using electronic tickets

ABSTRACT

A method, software and apparatus facilitates one or more third-party agents to securely access a customer&#39;s or other first party&#39;s private personal and financial data or other such confidential information from a second party, preferably on the Internet. A security document or ticket is presented to the second party for verifying the customer&#39;s consent to grant such access to the third party. The second party only communicates such confidential information to the third party if the security document is found to be valid. The security document, which can be at least partially encrypted, can also include a preselected expiration time, beyond which it is not valid.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is entitled to the benefit of, and claims priority to,U.S. Provisional Patent Application Ser. No. 60/223,825, filed Aug. 8,2000 entitled “INTERNET THIRD-PARTY AUTHENTICATION USING ELECTRONICTICKETS.”

BACKGROUND AND SUMMARY OF THE INVENTION

The invention relates generally to computer information security and theInternet, and more specifically to methods that permit one or morethird-party agents to access customers' private personal and financialdata or other confidential information on the world-wide-web. Theinvention was originally designed as a method for banks and bankcustomers to mutually approve one or more third party agents (such asaggregators, for example) to access customer confidential data via theInternet. It is also applicable, however, in any situation involvingcomputers where an agent's computer or computers act as an intermediarybetween computers of two other parties and where access to certaininformation is to be limited, whether or not the information isconfidential.

The Consumer Problem

When the World Wide Web (“the web”) was invented in 1990, security wasnot a major concern because it was primarily used to share scientificresearch. The initial concept was for unlimited, open, public access todocuments. As the web became popular, however, the need for securityincreased. Web sites developed schemes with usernames and passwords toprotect confidential web pages. And, in 1995, SSL encryption became thestandard method to protect confidential data transmitted over the publicInternet. By 1999, consumers started to become confident in the securityof Internet transactions, and Internet commerce became commonplace.Millions of consumers regularly made purchases, paid bills and performedcommon banking and brokerage transactions using the Internet.

Today, a typical consumer might have access to dozens of secure websites for shopping and financial services. Because each site has aunique look and feel, customers must learn how to navigate eachindividual site. Each site also has a unique security identification andauthentication scheme, forcing each customer to keep track of dozens ofusernames and passwords, PINs and code words. These factors may beconfusing and frustrating for consumers. So, while the Internetrevolutionized the way consumers access information, taking advantage ofit is often difficult and cumbersome. Obtaining a consolidated view of acustomer's Internet or on-line accounts could easily require hours ofmanual effort, working at a computer, visiting many web sites.

The Aggregator Solution

An aggregator is a web service that consolidates a consumer's financialand personal information and presents it in a concise, easy-to-readfashion. An aggregator accesses shopping and financial service web sitesto extract customers' data and repackages that data for presentation onthe aggregator's web site. After enrolling with an aggregator, customersonly need to learn how to navigate the aggregator's web site.Furthermore, customers must remember only one username/passwordcombination, instead of dozens.

The enrollment process typically involves setting up a username andpassword to access the aggregator's web site. This username/passwordbecomes a very powerful “master password” because it gets linked to thecustomer's other accounts and passwords. In addition to creating masterpasswords, customers also enter details about each bank, brokerage andshopping web site they want the aggregator to access on their behalf.Details include usernames, passwords, account numbers and other secretor confidential information required to access aggregated web sites.(Not all aggregators know how to access all financial and shopping websites, so the aggregator must support the bank, brokerage and shoppingweb sites a customer intends to use.) Once the aggregator has theinformation necessary to access all of a customer's accounts, however,the aggregator will work behind the scenes on the Internet to assemblethe details about the customer's personal financial life or otherconfidential information.

When a customer visits the aggregator's web site, the aggregator willtypically display a list of bank, credit card, brokerage, shopping andother financial accounts, along with associated balances, in a concise,consistent and consolidated fashion. The aggregator's site usually alsohas features to “drill down” into details about any account, showingtransactions, history and trends. If the aggregator offers bill paymentfeatures, customers can also view on-line versions of bills andstatements, including transaction details. Many aggregators also allowcustomers to schedule bill payments—where the aggregator moves moneyfrom customers' bank accounts to vendors or other accounts eitherelectronically or by mailing actual checks. Since an aggregator maytrack uncleared transactions, the financial information kept by anaggregator may be more up to date than customer's account data at eachbank, brokerage or vendor. An aggregator makes customers' on-linefinancial life much easier to manage. The aggregator is, in effect, apersonal financial agent on the Internet.

How Do Aggregators Work?

Many aggregators use a technique known as “screen scraping” to accesscustomers' information at various financial and shopping web sites.During screen scraping, the aggregator simulates a human and Internetbrowser accessing each web site. A computer program takes the place of akeyboard and mouse by supplying the expected input. Much like a humanreading results on a screen, the computer program “reads” and stores theinformation returned by each aggregated site.

Screen scraping is not a perfect technology, however. If a web sitechanges its appearance or process flow, the aggregator may not be ableto accurately obtain (or scrape) the information from the web site.Aggregators must constantly monitor aggregated web sites in an attemptto keep their computer programs current with each site.

In contrast, some aggregators have tightly coupled relationships withvarious financial institutions. This enables them to use more advancedtechniques such as Interactive Financial Exchange (IFX), Open FinancialExchange (OFX) or eXtended Markup Language (XML), for example, toefficiently transfer account information. However, these techniques havenot yet been widely adopted.

Risks of Aggreation

Many consumers recognize the benefits provided by aggregators, but feeluncomfortable providing aggregators unlimited access to passwords andother private information. If the security at an aggregator's web siteis compromised, unscrupulous parties could steal customers' private andconfidential information and passwords.

When banks and other commercial web sites created theirusername/password schemes, they intended that only the consumerassociated with each username know the secret password. In many cases,banks don't even store actual passwords. Instead, they store only amathematically hashed value based on the password, which is enoughinformation necessary to detect a valid password. In other words, manybanks don't actually know a password, but they can determine if thecustomer really knows it. Storing password information in this mannerreduces the likelihood of password theft by bank employees. This methodalso helps prevent password theft by Internet hackers.

When consumers provide passwords to an aggregator, they reduce thesecurity and safety of their passwords because they are stored at anaggregator's computing facility in a reproducible form. Even if theaggregator stores encrypted passwords, this is less secure than amathematical hash, because, unlike a bank, the aggregator can reproducethe original passwords. An aggregator's unscrupulous employee or anInternet hacker could exploit this risk and steal passwords.

Banks, brokerages and retail companies, for example, created their websites with the intent that actual customers would access their sites.They didn't intend for aggregators' automated systems to extractcustomer data. The web sites' auditing and record logging mechanismswere originally intended to track actual customers initiatingtransactions. Commercial web sites need a way to audit and recordaccesses by aggregators distinctly from actual customers. These auditmechanisms should have a way to determine if a customer actuallyapproved each aggregator's access.

If a customer discontinues the use of an aggregator, he or she wouldrequest the aggregator to disable their username and clear theirpersonal information. However, this does not guarantee that thecustomer's confidential information has been removed. For a variety oflegitimate reasons, or in the event of error, the aggregator mightretain records of the customer's associated accounts, usernames andpasswords. This retention might be temporary, but could even bepermanent. The customer has no method to detect when an aggregatoraccesses his accounts, so they cannot easily feel confident that allaccess has been terminated.

The risks described here, plus financial liability and other regulatoryrisks, are roadblocks to widespread acceptance of aggregators byconsumers, commercial web sites and government regulators.

Public Key Cryptography and Digital Certificates

Much of public key cryptography relies on unique properties of extremelylarge prime numbers (hundreds or more digits long) and a techniquepatented in 1983 by R. L. Rivest, A. Shamir, and L. M. Adleman. Thistechnique, commonly known as RSA encryption (named for its inventors),allows any general-purpose computer to generate a pair of mathematicallyrelated numbers, known as encryption keys (or just “keys”), within a fewseconds. Typically, one of the keys is called the private or secret keybecause the key owner must protect and secretly store the only copy ofthe private or secret key. The other number is called the public keybecause it can safely be shared with anyone.

Although the RSA methods can easily generate a key pair within a fewseconds, the process to reconstruct a key pair is extremely difficult.If one key in a pair is lost, it could take the world's fastestcomputers many years to decompose the known key and recalculate the lostkey. This disparity in decryption is the strength of public keycryptography. If someone has your public key, it is very difficult(almost impossible) for him or her to determine your private or secretkey. If you have someone's public encryption key, you can use RSA'sencryption techniques to encode a message or file that only that personcan decrypt and read. The message recipient must have the private key(which is associated with the public key) and use RSA's decryptiontechniques to decode the message.

Conversely, if someone uses his or her private or secret key to encryptsome data or its digest, then anyone with access to that person's publickey can decrypt the data or its digest back to its original form.Assuming that the originator protects his private or secret key, nobodyelse could have sent the original encrypted message—in effect amathematical signature proves who originated the message. (Within thecomputer security industry, this exemplary security device is commonlyknown as a digital signature.)

The public and private or secret keys complement each other. If one ofthe keys encrypts (or locks) some data, the other complementary keydecrypts (or unlocks) the data. Each customer, commercial web site andaggregator must have a unique public and private key pair. Rather thaninventing methods to manage the storage of private keys and sharing ofpublic keys, this invention relies on the existing public keyinfrastructure (PKI). With PKI, when an entity (person or company)creates a key pair, they register the public key with a certifyingauthority (CA). The CA verifies the identity of the entity and issues adigital certificate, which has been digitally signed by the CA.

The digital certificate serves as a tamper-resistant electronicidentification document for an entity. The digital certificate includesthe entity's public key. (Only the entity that generated the key pairshould have access to the associated private or secret key.) Much of thesoftware required to manipulate and store digital certificates andassociated keys already exists as commercially available software. MostInternet web browsers and web servers have the capability to storedigital certificates and keys, and software libraries, such a RSA'sCryptoJ can perform public key cryptography. It is expected that thisinvention will be implemented using tools such as these, among others.

Although the technology exists, and the software is readily available,the use of digital certificates has not yet been widely adopted byconsumers. By the year 2000, the United States federal government andmany states approved the use of digital certificates and digitalsignatures as acceptable authentication mechanisms forpublic-to-government transactions. As public and commercial acceptanceof digital signatures become commonplace, it is expected that mostcommercial institutions will either issue or otherwise assist customersto obtain digital certificates.

SSL Encryption

The Secure Sockets Layer (SSL) protocol was developed by NetscapeCommunications, Inc. as a way to securely move data over a publicnetwork, notably and typically over the Internet. SSL uses public keycryptography, specifically RSA's encryption methods, for example, toestablish a secure “session” between two computers connected via theTCP/IP protocol. Public keys, usually obtained from digital certificatesand associated private or secret keys may be used to identify(authenticate) one or both computers in a TCP/IP conversation. Once anSSL session is established, it is very difficult (almost impossible) fora third party to eavesdrop and examine the data flowing between the endcomputers. This invention assumes that SSL encryption, or similarencryption protocols among those readily known by those skilled in theart, will be typically used for all secure communications betweencustomers, aggregators and commercial web sites.

Optionally, SSL authentication may also be used to verify the identityof one or both parties involved in each communication. If both partiesuse public keys from digital certificates, for example, and associatedprivate keys in conjunction with SSL to authenticate their identitieswith each other this is commonly referred to as SSL mutualauthentication. If only one party uses a private or secret key anddigital certificate for one end of an SSL session, this is commonlyreferred to as SSL single-end authentication.

Although this invention works best with SSL mutual authentication, itmay also be used with SSL single-end authentication or even if SSLauthentication is not used at all. In these cases, the parties mustselect some other form of verification or authentication (e.g.,usernames and passwords), which should occur immediately after each SSLsession is established. This invention requires that the partiesinvolved in electronic communications, for example, have somehowverified or authenticated their identities with each other, using SSLauthentication, for example, or similar techniques well-known to thoseskilled in the art.

Other known encryption/decryption methods will also occur to thoseskilled in the art, including those using symmetric, asymmetric, messagedigests (mathematical hashes), or other encryption schemes (includingthose using multiple-use or one-time use keys), for example.

Using the present invention, a tamper-resistant security document, suchas an electronic document, known as a ticket, is created and approved bytwo consenting parties to allow a third party (or even more parties) toaccess private and confidential personal and financial data on theInternet (world-wide-web). The electronic ticket or other types ofsecurity documents can also have a limited lifetime, allowing theconsenting parties to control the third party's duration of access.

Some of the exemplary features, objects or advantages of the presentinvention include:

-   -   (a) to provide an electronic document (ticket), for example,        that proves that two or more parties consent to allow a third        party (or more parties) secure verified access to confidential        information;    -   (b) to create an electronic document (ticket), for example, that        is very difficult (almost impossible) to forge;    -   (c) to create an electronic document (ticket), for example, that        is very difficult (almost impossible) to modify without the        creator's consent;    -   (d) to create an electronic document (ticket), for example, that        is only useful to the intended parties—a stolen ticket can't be        successfully used by a thief;    -   (e) to create an electronic document (ticket), for example, that        eliminates, or least substantially minimizes, damaging security        consequences if it is lost or stolen;    -   (f) to create an electronic document (ticket), for example, that        only needs to be stored by a single party;    -   (g) to create an electronic document (ticket), for example, with        a limited lifetime—the ticket can't be used after it expires;    -   (h) to create an electronic document (ticket), for example,        whose expiration date and time (“expiration time”) is agreed        upon by all parties;    -   (i) to create an electronic document (ticket), for example, that        can be used by a third party an unlimited number of times (or        alternately, if desired in particular situations, for a        specified limited number of times) during the ticket's lifetime;    -   (j) to create an electronic document (ticket), for example,        containing a serial number allowing the ticket's approval and        usage to be monitored and recorded for auditing purposes;    -   (k) to create an electronic document (ticket), for example, that        allows the consenting parties to insert optional information        into the ticket for subsequent, future usage; and/or    -   (l) to create an electronic document (ticket), for example, that        may be safely substituted in situations where a traditional        password would normally be used.

Possible further objects and advantages are to provide an electronicdocument (ticket) that can be initiated by any of the three or moreparties, that allows customers, for example, to use third party agentsto access confidential financial and personal information in a safe andsecure and verifiable manner without requiring customers to revealconfidential passwords, and that also utilizes existing Internettechnologies. Other objects, advantages and features of the inventionwill readily occur to those skilled in the art from the followingdescription and appended claims, taken in conjunction with theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A and 1B are flow diagrams showing an exemplary relationship ofthe entities involved in exchange of confidential information inrelation to the invention.

FIGS. 2A through 2F are flow diagrams showing an exemplary sequence ofevents performed in the context of the invention.

FIG. 3 is an exemplary illustration of what a customer sees on acomputer screen during the approval of an electronic ticket or othersuch security document according to the invention.

FIG. 4 is a flow diagram showing an exemplary simplified flow of aticket's request, approval and usage between three parties (in theillustrated example): an aggregator (the requester), a commerce web site(the originator and first approver), and a customer (the finalapprover).

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

For purposes of illustration, FIGS. 1 through 4 (taken in conjunctionwith the following description) illustrate merely exemplary embodimentsof the invention, shown in the context of a commonly-encounteredcustomer, aggregator and bank relationship for securely communicating acustomer's personal and private banking, commerce-related information orother confidential information over the Internet. One skilled in the artwill readily recognize that the present invention is equally applicableto other contexts in which confidential information is securelycommunicated among three or more parties, and even those usingcommunication media other than the Internet.

As illustrated in FIG. 1A, commerce web sites 103, 104 provide customers101 access to customer private or confidential data 105 using theInternet 102, standard operating software 107, 112 and computers 103,110. Although FIG. 1A only shows one instance of customer private data105, it is not uncommon for a customer 101 to have data scattered atmany commerce web sites 103, 104.

As illustrated in FIG. 1B, an aggregator's web site 116 uses theInternet 102 and standard Internet software 121 to access many commerceweb sites 103, 104 on behalf of the customer 101. An aggregator 116 willaccess a customer's private data 105 from various commerce web sites103, 104 and consolidate (with database software 121) the customer'sprivate data 117 for later access by the customer 101. When a customer101 accesses the aggregator's web site 116, his consolidated privateinformation 117 is presented in a concise, easy-to-use fashion. Acustomer 101 need only access the aggregator's web site 116 to viewtheir consolidated private or confidential information 117 originallyobtained from many commerce web sites 103, 104.

Most commerce web sites 103, 104 and a customer's general operatingsoftware (such as an Internet browser) 112 use SSL encrypted sessions108, 109 to protect confidential data as it traverses the publicInternet 102. SSL uses public key cryptography, in conjunction withprivate keys 106, 111 and public keys (contained in digital certificates114, 115) to authenticate the identity of one or both parties involvedin each SSL session 108, 109.

Commerce web sites 103, 104 create a public/private key pair suitablefor use with RSA encryption and SSL software 107, 112, for example. Acommerce web site 103 also registers its public key with a certificateauthority 113, who will issue a digital certificate 114 containing thepublic key of the commerce web site 103. Techniques for registering,sharing and processing digital certificates are well-known and arealready widely available with standard Internet operating software 107,112, and are thus not described here. The invention assumes that digitalcertificates 114, 115, 127, for example, and/or the public keysnecessary for SSL and RSA encryption, are easily available to allparties that need access to them.

Digital certificates 114, 115, 127 and private or secret keys 106, 111,118, for example, may be used to authenticate the identity of bothparties involved in any SSL session 108, 109, 122, 123, 124 using SSLmutual authentication. Alternatively, SSL single-end authentication maybe used to create an SSL session 108, 109, 122, 123, 124 if only oneparty possesses the necessary private key and digital certificate.Although this invention works best with SSL mutual authentication inmost situations, it may also be used with SSL single-end authenticationor even if SSL authentication is not used at all, provided that analternate means to authenticate the non-SSL authenticated party isutilized. Alternate authentication means are beyond the scope of thisexemplary illustration of the invention, however they typically involvesome sort of password scheme.

As illustrated in FIG. 1B, this exemplary embodiment of the inventionincludes software 120, 125, 126 to create and process security documentsor tickets 119. Although this invention was designed to use the Internet102, more specifically, the world-wide-web technology of the Internet,it is also suitable for use when all or part of the information flowsover private networks or other systems or mediums.

Software 120 at an aggregator's web site 116 sends a ticket 119 to eachcommerce web site 103, 104 for each access to a customer's private data105. Ticketing software 125 at a commerce web site knows how to validatea ticket 119 presented by software 120 from an aggregator's web site116. Once a ticket 119 is validated, the aggregator 116 is permittedaccess to the customer's private data 105 for the duration of thesession 122. If, however, an aggregator's web site 116 doesn't have avalid ticket 119 for the specific customer 101 and commerce web site103, 104, the aggregator's ticketing software 120 will send a ticketrequest to the commerce web site's ticketing software 125.

Ticketing software 125 at the commerce web site 103 creates the firstpart of a new ticket and digitally signs it with the commerce site'sprivate key 106. All or part of the new ticket is then encrypted withthe customer's public key 115 and sent back to the aggregator's web site116. If the customer 101 is not already on line with the aggregator'sweb site, when he or she next visits the aggregator's web site 116,ticketing software 120 then forwards the encrypted, new ticket toticketing software 126 contained in the customer's computer 110.

Ticketing software 126 in the customer's computer 110 decrypts the newticket, validates the commerce site's digital signature against theproper digital certificate 114, and prompts the customer 101 to acceptor reject the new ticket. The customer 101 can also be given a chance toadjust the ticket's expiration date and time. Based upon the customer's101 response, the ticketing software 126 completes the ticket (includingthe customer's accept or reject status) and digitally signs the ticketwith the customer's private key 111.

The customer's ticketing software 126 and Internet browser 112 thenforwards the completed ticket from the customer's computer 110 back tothe aggregator's web site 116. The aggregator ticketing software 120then stores the ticket 119 for later use.

In FIG. 2A, a typical procedure for granting and using an exemplaryticket is described generally, but not exclusively, as set forth below.

Consumers need a way to approve aggregators' access to their variousaccounts without giving away their passwords. The ideal method shouldallow access to be easily revoked and audited. The inventioncontemplates the use of temporary, electronic tickets to fulfill theseneeds.

Tickets leverage existing Internet technology and public keycryptography to create tamper-resistant documents (tickets) which areused to approve account access. Tickets can be created by banks,brokerage firms, shopping sites and other commerce web sites, approvedby customers, and given to aggregators. An aggregator's computer systemthen presents a ticket for each account it attempts to access.

In the detailed description of exemplary versions of the invention thatfollows, it is assumed that all parties have the necessary computers,hardware and software to access the Internet, utilize digitalcertificates, perform appropriate encryption, and process ticketsutilizing methods described in this invention.

In step 201 of FIG. 2A, relationships 202 are identified andestablished, if not already done so as described above, between acommerce web site, an aggregator web site and a customer. Theserelationships need only be established once and may be skipped (proceedto step 210 in FIG. 2B) if already established. As needs change, any ofthe steps 202 through 209 (in FIG. 2B) may be repeated in order toupdate the nature of the relationships.

In step 203, a commerce web site obtains a digital certificate (if notalready done) for use as an identity to create SSL encrypted sessionsand digitally sign documents. Most Internet web server software includesthe ability to utilize digital certificates and associated private keys.

In step 204, an aggregator's web site similarly obtains a digitalcertificate (if not already done) for SSL authentication. Althoughstrongly suggested, the invention does not require that the aggregatorhave a digital certificate, provided that a suitable alternate meansexists for the commerce web site to authenticate the identity of theaggregator.

In step 205, an aggregator must register an identity with each commerceweb site that it intends to access. In most cases, this will requireregistering an aggregator's digital certificate with a commerce website. Alternately, a commerce web site could issue some sort of passwordto each aggregator. In either case, the commerce web site must be ableto identify the aggregator during each access to the commerce web site.

In step 206, before an aggregator can access a customer's data, thecustomer must be known by the commerce web site. Typically, this willinvolve the customer joining an on-line shopping site, or signing up foron-line account access with a bank or brokerage house, for example.

In step 207, the customer obtains a digital certificate from acertificate authority agreeable to both commerce and aggregator websites, or otherwise establish an acceptable authentication among them.Preferably, commerce and aggregator web sites should be able to verifyand trust the authenticity of the customer's digital certificate.

In step 208, after all other relationships have been established, acustomer registers an identity at an aggregator's web site. Typically, acustomer will register his, hers, or its digital certificate with theaggregator. An aggregator may also issue some sort of password to eachcustomer, however, this does not preclude the need, at least in thisexample, for each customer to possess a digital certificate.

In step 209, shown in FIG. 2B, the customer will inform the aggregatorabout each of his or her accounts at each commerce web site that he,she, or it wants the aggregator to access. This step may be repeatedwhen the customer adds new accounts.

Steps 210 and beyond may be performed at any time, initiated by theaggregator's site autonomously of the customer, for example, orspecifically requested by the customer initially as illustrated in step209.

In step 210, if an aggregator has a ticket (electronic document) for aspecific commerce web site, which is necessary to access a specificcustomer's accounts at that web site, then step 211 can be executed,otherwise, step 217 can be executed, as shown in FIG. 2C.

In step 211, a ticket optionally, but preferably, has at least twoexpiration date/time (“expiration time”) stamps, which can be one set bythe commerce web site and the other set by the customer. Using theearlier or earliest expiration date/time stamp, it can be determined ifthe ticket has expired. In this regard, this exemplary version of theinvention assumes that all computer systems involved in ticketprocessing use a unified time zone, such as UCT or GMT time zone, whencomparing these date/time stamps. If the ticket has expired, step 216can be executed, as shown in FIG. 2C, otherwise step 212 can beexecuted.

In step 212, an aggregator sends a copy of the ticket associated withthe customer's accounts to a commerce web site for approval.

In step 213, a commerce web site verifies the expiration date/timestamps, then verifies the digital signatures on the ticket. The tickethas at least two digital signatures—one for the commerce web site'sportion of the ticket and another for the customer's portion of theticket. Both digital signatures must prove or verify that both partiesissued the ticket and that the ticket hasn't been tampered with.Finally, the commerce web site verifies that the ticket is associatedwith the aggregator requesting the account access. Assuming that allchecks pass and the ticket is accepted, then step 214 can be executed,as shown in FIG. 2B. Otherwise, step 216 can be executed, as shown inFIG. 2C.

At step 214 in FIG. 2B, the commerce web site permits the aggregator toaccess the customer's data. Assuming that steps 202 through 209 wereskipped, it was not necessary for the customer to approve thisparticular access by the aggregator because the aggregator possessed avalid ticket. As long as the ticket remains valid, the aggregator willtypically have unencumbered access to the customer's data, withoutadditional approval from the customer. For this reason, expiration datesand times (if used) should be set to short, reasonable values.

The aggregator might access a customer's data at the commerce web siteusing screen scraping techniques, for example, where the data isextracted from data streams intended (by the commerce web site) to bedisplayed on a customer's browser. As an incentive to use this ticketingsystem, aggregators might be given a more formalized data feed utilizingXML, IFX, OFX or structured records, for example.

In step 215, the aggregator closes the session with the commerce website. Any further or future access starts over at step 201.

In step 216 of FIG. 2C, an aggregator has a ticket for a specificcustomer and a specific commerce web site, but it has been proveninvalid. Since the ticket is no longer good, the aggregator purges itfrom data storage.

In step 217, an aggregator does not have a ticket for a specificcustomer and a specific commerce web site, so it sends a request for anew ticket to the commerce web site.

In step 218, the commerce web site creates a new ticket, which is merelya document with data fields for items on the ticket. Although notrequired by the invention, a document may be formatted with XML-styletags common with Internet documents.

In step 219, the commerce site adds the aggregator's identification tothe ticket. Since the aggregator has authenticated with the commerce website, the identity may be obtained from the established session. Thisidentity is used to validate the aggregator's access in step 213 of FIG.2B. A serial number (for auditing purposes) and the first expirationdate/time (“expiration time”) can also be added to the ticket. Thecommerce web site may optionally add other fields to the ticket for itsown use.

In step 220 of FIG. 2D, using the Internet standard s/MIME encodingmethod, for example, the commerce web site then digitally signs the newticket. The ticket is not yet complete, however, so the signature onlycovers those portions created by the commerce web site. The digitalsignature is created with the commerce web site's private encryptionkey. Anyone may verify the signature by accessing the digitalcertificate (and public key) associated with the signature.

In step 221, using the Internet standard s/MIME encoding method, forexample, the commerce web site then encrypts all or part of the newticket using the customer's public key obtained from the customer'sdigital certificate. The commerce web site then forwards the new,encrypted ticket back to the aggregator in step 222.

In step 223, since only the customer has the private keys necessary todecrypt the ticket, the aggregator must forward the ticket forprocessing to the customer's computer system. If the customer is notcurrently accessing the aggregator's web site, step 224 is executed towait for the customer. Otherwise, step 225 in FIG. 2E can be executed.

In step 224 of FIG. 2D, an aggregator has a ticket that needs to beapproved by the customer and wait for the customer to access theaggregator's web site. Thus, in step 225 of FIG. 2E, the aggregatorsends the new, encrypted ticket to the customer's computer system (suchas by way of an Internet browser) and waits for the reply.

In step 226, ticketing software running within the customer's browseruses the customer's private encryption key to decrypt the new ticket.The software also verifies the commerce web site's digital signature andany expiration date/time stamp. In step 227, the customer is prompted toapprove the ticket (see FIG. 3 for an exemplary screen view). The promptincludes enough information to identify the aggregator, the commerce website and the desired accounts. The prompt also includes the ability forthe customer to adjust (shorten) the ticket's expiration date/time(“expiration time”). The ticket will often contain a second expirationdate/time stamp for the customer. Also, the date/time stamp should beencoded with a single unified time zone, such as UCT or GMT, asmentioned above. The software should accordingly adjust the displayedexpiration time to the customer's local time zone. Then, in step 228,the prompt provides the customer with the ability to accept or rejectthe ticket requested by the aggregator (see FIG. 3).

In step 229 of FIG. 2E, the ticketing software running in the customer'sbrowser adds the second expiration date/time (if such expiration timesare used in the particular application) plus the customer's accept orreject status code to the ticket. In step 230 of FIG. 2F, using theInternet standard s/MIME encoding method, for example, the ticketingsoftware running in the customer's browser digitally signs the ticketusing the customer's private encryption key. The ticketing softwarerunning in the customer's browser sends the completed ticket to theaggregator's web site n step 231.

In step 232, the aggregator can examine the accept or reject status codeto determine if the ticket was approved by the customer. If the customerapproved the ticket, step 210 can be executed, as shown in FIG. 2B.Otherwise, step 233 is executed, indicating that the customer hasrejected the aggregator's request for a new ticket, and the aggregatormay not access the customer's accounts.

Possession and storage of tickets is typically the responsibility of theaggregator. Customers and commercial web sites usually do not need tostore a copy of each ticket, although they may do so for diagnostic,auditing or other purposes. If an aggregator loses a ticket, though,there is no way to replace it. The aggregator must request that a newticket be generated.

A commercial web site need only verify the validity of a ticket in orderto authenticate an aggregator's access to a customer's data. Thisverification typically includes checking the digital signatures on theticket against digital certificates maintained within a public keyinfrastructure. The signatures help ensure the authenticity of theticket and that the ticket has not been tampered with.

Because ticket expiration is crucial to limiting account access,commercial web sites must check both expiration times on each ticket.Typically, but not necessarily, the earliest expiration time shoulddetermine when a ticket actually expires. Dual expiration times allow acustomer and commerce web site to mutually agree upon the ticket'slifetime in a secure manner.

Although the exemplary usage scenarios presented in FIGS. 2A through 2Fdepict a single ticket for a given customer-web site-aggregatorcombination, more than one ticket might be used when varying levels ofaccess are required. For example, one ticket might permit read-onlyinquiries about existing account transactions; and a second ticket mightpermit transactions to be initiated by an aggregator. Each ticket canhave space for optional information to be inserted by the commercial website and/or the customer that may be used to determine the type ofaccess granted to a third party.

It is expected that all confidential communications among the customer'sweb browser, the aggregator, and the commercial web site will typically,but not necessarily, employ industry-standard SSL encryption. However,it is not necessary to securely store or encrypt a completed ticketbecause the ticket is bound to, and only works with, a specificcustomer, aggregator and commercial web site. A stolen ticket is oflittle value to anyone except the aggregator. Moreover, anyone can testthe validity of a ticket.

Typically, ticket data, digital signatures and ticket encryption will beencoded into computer messages using standard Internet s/MIME encodingtechniques. Internet s/MIME encoding has been widely adopted by mostInternet mail, web browser and web server software.

FIG. 3 illustrates an exemplary situation where a customer prompts for anew ticket request, typically, but not exclusively, as described below.The customer is preferably given the ability to grant or deny therequest and adjust the expiration time, if such times are used in aparticular instance. Thus, FIG. 3 merely illustrates one example of howthe customer can be prompted. Any of a wide variety of other suitableprogramming dialogs known to those skilled in the art can also be used.

On customer screen 301, a ticket request is usually processed anddisplayed by software running within a customer's Internet browser. Thissoftware may be incorporated by browser manufacturers or dynamicallyadded to browsers with standard Internet applet technologies, such asJava or ActiveX, for example. Data fields 302 describing the parties andaccounts involved with the ticket request are extracted from the ticketand displayed as part of the prompt. The customer can use a mouse (orsimilar pointing or other input device) to finish (close) the ticketrequest.

At 304, the customer may adjust the ticket expiration date/time (If suchexpiration times are use in the particular application) by using aslider-style control with a mouse, for example. One skilled in the artwill readily recognize that other input devices can be used for this andother customer responses.

At 305, the customer chooses to either grant or deny access to theaggregator (agent). The default should typically be set to deny, so thatthe customer has to intentionally and affirmatively choose to grantaccess. When the customer chooses “Finished” at 303, the results fromthis screen prompt are coded into the ticket, digitally signed orotherwise authenticated by the software running in the customer'sbrowser and returned to the aggregator's web site.

FIG. 4 illustrates an exemplary simplified flow of the ticketprocessing, typically but not exclusively, as described below.

In step 401, an aggregator web site 407 requests a new ticket to accesscustomer accounts at a commerce web site 408.

In step 402, commerce web site 408 creates a new ticket, digitally signsit, encrypts it with the customer's public key and sends it to theaggregator 407.

In step 403, aggregator's web site 407 forwards the encrypted ticket tocustomer's computer 406 for approval.

In step 404, web software in the customer's computer 406 decrypts theticket, prompts the customer to adjust the expiration date/time, andprompts the customer to accept or reject the ticket request. Thesoftware then adds a second digital signature to the ticket and sends itback to the aggregator 407.

At step 405, the aggregator 407 can then use the ticket to securelyaccess customer accounts at the commerce web site 408.

One skilled in the art will readily recognize that this exemplaryticketing system provides a reliable, secure, reusable, tamper-resistantticket that allows at least a specific third party (aggregator) toaccess to private or confidential customer data at various commercialweb sites without knowledge of the customer's passwords. Furthermore,each reusable ticket can be set to expire at a customer-selectedexpiration time or one that is mutually agreed upon by both a customerand a commercial web site. The use of this ticketing system can alsopromote improved auditing of aggregator's activities at commercial websites. The exemplary ticketing system can also leverage existingInternet and encryption technologies to allow for easy implementation.

The foregoing discussion discloses, and describes merely exemplaryembodiments of the present invention for purposes of illustration only.One skilled in the art will readily recognize from such discussion, andfrom the accompanying drawings and claims, that various changes,modifications, and variations can be made therein without departing fromthe spirit and scope of the invention as defined in the followingclaims.

1-90. (canceled)
 101. A method of creating an electronic document thatdescribes a mutually agreed upon arrangement between at least threeparties, the method comprising: initiating a computer-generatedelectronic document by a party, wherein the electronic document resideswithin a computer system of at least one of the parties and theelectronic document comprises verifying information from at least two ofthe parties to establish multiple-authorship of the electronic document,adding expiration times to the electronic document by at least two ofthe parties, and obtaining agreement of all of the parties to use theearliest expiration time of the electronic document.
 102. The methodaccording to claim 101, wherein the electronic document is stored on acomputer by at least one party.
 103. The method according to claim 101,wherein a third party has use of the electronic document for anunlimited number of times prior to expiration of the document.
 104. Themethod according to claim 101, wherein the electronic document furthercomprises a serial number.
 105. The method according to claim 104,wherein the serial number is used for auditing or tracking purposes.106. The method according to claim 101, wherein at least a portion ofthe electronic document is encrypted.
 107. The method according to claim106, wherein at least a portion of the electronic document issymmetrically encrypted.
 108. The method according to claim 106, whereinat least a portion of the electronic document is asymmetricallyencrypted.
 109. The method according to claim 101, wherein theelectronic document comprises a digital signature of at least two of theparties.
 110. The method according to claim 106, wherein the encryptedportion is capable of decryption using an encryption key.